Kada se nešto ne uradi kako treba na vreme ili u pravo vreme, onda dugovi dođu na naplatu pre ili kasnije, uz dodatnu cenu i moguću štetu. Propusti i greške, bilo da su svesno ili nesvesno učinjeni ranije, pojave se najčešće u nevreme kao svojevrsni duhovi iz prošlosti.
Tako je u raznim oblastima života, pa i u razvoju softvera. Problemi prouzrokovani greškama i propustima u starom programskom kodu, od kojih su neki sa vrlo ozbiljnim posledicama, iskrsavaju sve češće. U ovom tekstu navodim nekoliko primera koji su se pojavili prošle i ove godine. Nakon toga slede preporuke kako bi ubuduće mogli da se umanje ili izbegnu ovakvi problemi.
Jedan od nedavno otkrivenih propusta u softveru dobio je, na interesantan način, upravo ime GHOST ili, u prevodu, duh.
Trka u razvoju softvera se neverovatno ubrzava, sa ciljem da bi se što pre izašlo na tržište i uzeo svoj deo kolača, a to ima svoju cenu, često veoma veliku. U novije vreme (skoro) niko ne razvija stvari od početka, već se naslanja na postojeći kod i projekte. Nažalost, sigurnost kao deo razvojnog tj. celokupnog životnog ciklusa softvera nije ranije bila, a ni danas još uvek nije prepoznata kao značajan faktor u većini timova i tom problemu se ne pridaje potrebna pažnja.
Ne treba zanemariti i čestu pojavu da nivo svesti o problemima sigurnosti softvera nije razvijen generalno, a ponekad ni kod softverskih arhitekata, programera i ostalih učesnika u projektovanju, razvoju, testiranju i održavanju softvera.
Posledica je da propusti u starom kodu, kako otvorenom i slobodnom, tako i u komercijalnom i vlasničkom, koji često nisu adekvatno provereni, testirani i ispravljeni na vreme, dovode do sve ozbiljnijih problema, gubitaka i štete. Situacija u novije vreme je nešto bolja u smislu obučenosti i pažnje koja se posvećuje problemu sigurnosti, ali i dalje daleko od zadovoljavajućeg nivoa. Problema ovog tipa će biti sve više, između ostalog i zbog rasta ukupne količine i složenosti softverskog koda. U svojoj prognozi za 2015. godinu, Carl Leonard, Principal Security Analyst iz firme Websense kaže:
"Old source code is the new Trojan horse waiting to be exploited, and open-source code is only the beginning. With so much code written and in use, it's impossible to catch every dormant exposure point until they've been executed. Because of this, any time source code is altered or integrated as part of an application or service upgrade, these unknown systemic vulnerabilities have the potential to expose networks to attack."
Ovde ću navesti nekoliko primera poznatih sigurnosnih propusta koji su bili tema brojnih diskusija tokom protekle i početkom ove godine.
Napomena: Sasvim slučajno je ispalo da se, na listi u ovom tekstu, više problema odnosi na rešenja koja pripadaju grupi otvorenog kod (engl. open source). To ne znači da takvih problema ima manje u komercijalnom softveru, mnogi će reći - čak naprotiv. O tome se može voditi ozbiljna diskusija.
Takođe, u ovom tekstu se nisam bavio ranjivostima ili subverzivnim funkcijama u kodu namerno unesenim u kod. To je problematika koja je takođe interesantna i delimično se prepliće sa ovom.
GHOST
Firma Qualys je nedavno publikovala vesti o ranjivosti u Linux GNU C biblioteci (glibc). Uočeni nedostatak glibc biblioteke omogućava napadačima da daljinskim putem preuzmu kompletnu kontrolu nad Web serverom koristeći bag poznat pod imenom prekoračenje bafera (engl. buffer overflow) unutar glibc GetHOST funkcije. Odatle potiče i ime GHOST (duh). U početku je ovaj „duh" izgledao vrlo opasno, ali je kasnije firma Symantec objavila mišljenje koje je donekle umirujuće. Ipak, to je i dalje ozbiljan problem.
JasBug
Microsoft je nedavno izdao softverske „zakrpe" (engl. patch) da bi rešio 15 godina staru ranjivost u kodu, koja može biti iskorišćena od strane zlonamernih hakera kako bi se daljinskim putem preuzela kontrola na korisničkim računarima ili serverima koje rade na različitim verzijama Windows operativnih sistema. Radi se o fundamentalnom propustu u dizajnu funkcija operativnog sistema Windows, za koji je bilo potrebno 12 meseci da bude rešen. Ovaj problem postoji kod računara koji su konfigurisani da budu deo domena, dok kućni računari (koji nisu deo domena) ne bi trebali biti osetljivi na njega. Više o tome na stranicama sajta The Hacker News.
POODLE
Krajem septembra 2014. otkrivena je kritična ranjivost u SSLu verzije 3.0 koju je moguće iskoristiti za krađu poverljivih informacija, npr. lozinki i kolačića (engl. cookies) za pristup privatnim korisničkim računima na Internet stranicama. Ova ranjivost je dobila nazi POODLE ili pudla, a neki joj tepaju i pudlica.
Problem sa ovim propustom je što je SSL jedan od standarda za siguran prenos podataka, ali najpoznatiji i verovatno najviše korišten. Kolokvijalno se često koristi kao zajednički naziv za dva popularna standarda: stariji SSL i mlađi TLS. Masovno se koristi uz Web servise i faktički je neizostavan deo implementacije bilo kojeg e-commerce, SaaS i sličnih rešenja. Popularno rečeno: sve osetljive informacije danas putuju šifrovane po tom standardu, uključujući i mnoge privatne podatke i finansijske transakcije.
Problem SSL 3.0 protokola koji omogućuje POODLE napad je algoritamske prirode, tj. nije reč o loše programiranom delu softvera (što bi bilo relativno trivijalno ispraviti) već o propustu u samom algoritmu prenosa šifrovanih podataka.
Shellshock, Aftershock
Shellshock ranjivost poznata je i kao Bash Bug, rasprostranjena je na gotovo svim sistemima s Linux, Unix i MAC operativnim sustavima uključujuči i rutere, NAS uređaje i slično (svima koji koriste Bash i nisu „zakrpljeni" najnovijim „zakrpama" za Bash), a može napadaču omogućiti kontrolu nad ciljanim računarima. Ova ranjivost može potencijalno kompromitovati milione sistema.
Analiza istorije izvornog koda za Bash, pokazuje da je ova ranjivost prisutna u kodu od verzije 1.03 koja je puštena u septembru 1989. godine. Dakle, u kodu se nalazi već dobrih 25 godina.
Nakon otkrivanja Shellshock ranjivosti, usledile su vesti o ispravci tj. načinu rešavanja, a onda su se pojavile informacije o novim dodatnim ranjivostima koje su dobijale interesantna imena, kao što su Aftershock i slično.
Heartbleed
Biblioteka OpenSSL, koja ima široku primenu u obezbeđivanju mnogih sajtova uključujući i onih veoma osetljivih, našla se na udaru ranjivosti HeartBleed.
Ovo je ranjivost koja je prošlog leta (2014.) podigla na noge mnoge programere, sistem inženjere i druge IT profesije, ali nije ostala neprimećena ni od strane "običnih" korisnika računara. Mnogi su bili vro zabrinuti i to opravdano. Ranjivost je dobila i vrlo simpatičan logo i to je bio značajan element njene planetarne popularnosti.
Interesantno je da je propust unesen u kod 2011. godine od strane studenta na doktorskim studijama koji je bio zadužen za implementaciju HeartBleed ekstenzije za OpenSSL. On što je pomalo zabrinjavajuće, ali malo poznato široj pa i programerskoj javnosti je da su jedno od najčešće korišćenih otvorenih rešenja za SSL implementirala samo četiri programera! Tim koji bi trebao da pregleda i analizira kod, očigledno nije primetio bag u implementaciji. Tako nadograđena verzija 1.0.1. usvojena je za korišćenje u martu 2012. godine. Podrška za HeartBleed je omogućena standardno tj. by deafult, čime su verzije OpenSSL-a koje slede takođe ranjive. Opisani problem je otvoren od strane Google-ovog tima za sigurnost prvog aprila 2014.
CCS Injection Vulnerability
Ubrzo zatim, pojavila se i sledeća ranjivost CCS injekcija. Masashi Kikuchi je pisao na svom blogu o načinu otkrivanja CCS injekcije:
"Glavni razlog neotkrivanja greške više od 16 godina leži u nedovoljnoj analizi koda, posebno od strane stručnjaka koji su imali iskustvo u SSL/TLS implementaciji. Ako su već ljudi zaduženi za pregled koda imali dovoljno iskustva, trebali su ispitati kod OpenSSLa na isti način kao što ispituju svoj kod. Oni su mogli da detektuju problem."
Šta je ustvari CCS Injection ranjivost? OpenSSL u nekim verzijama nepravilno ograničava obradu ChangeCipherSpec poruka, što dozvoljava napadaču tipa „čovek u sredini" (engl. man-in-the-middle) da pošalje glavni ključ dužine nula u OpenSSL-OpenSSL komunikaciji. To dalje omogućava krađu sesije i dobijanje osetljivih informacija preko TLS rukovanja. U cilju izvođenja napada, potrebno je preseći vezu između klijenta i servera. Između ostalog, može se recimo ostvariti u neobezbeđenim bežičnim mrežama upadom u ruter ili drugi mrežni uređaj. Dakle, ovaj napad je bio moguć 16 godina pre nego što ga je Masashi pronašao. I koliko će još dugo biti moguć? Kako da znamo da u prošlosti niko nije bio upoznat sa ovim napadom? Malo je verovatno i moglo bi se očekivati je da je neko koristio sve mogućnosti opisanog propusta.
Zašto je toliko dugo trebalo da se otkriju i objave propusti?
Za otkivanje HeartBleed baga bile su potrebne dve godine. Posle toga, za otklanjanje propusta u široko korišćenim servisima bilo je potrebno još neko vreme. Upravo je takva pažnja izazvala i otkrivanje drugog, 16 godina prisutnog baga - CCS injekciju.
Ovo je dakle bio slučaj sa otvorenim kodom (OpenSSL) koga svako može detaljno pregledati. I skoro niko to nije uradio, verujući da će neko drugi pregledati kod i uveriti se da je sve u redu. Ili, barem niko, do nedavno, nije javno rekao da je otkrio da nešto nije u redu. Možemo nagađati da li su postojali ljudi koji su primetili propust, a ćutali o tome, a možda su ga i iskorišćavali. Koji motivi mogu da stoje iza toga, takođe može biti predmet nagađanja. Nikada ne možemo biti sigurni.
Za neke probleme je trebalo čak i četvrt veka (kao npr. Shellshock) ili petnaestak godina (primer je JasBug).
Ovi periodi su zaista predugi i ono što se moglo desiti ili se dešavalo u međuvremenu, možemo samo pretpostavljati.
Neka od pitanja koja se postavljaju su:
- Da li je neotkrivanje sigurnosnih problema posledica nemara i odsustva volje da se bilo ko time ozbiljno pozabavi?
- Koliko takvih problema u softveru još čeka da bude otkriveno?
- Koliko njih se trenutno iskorišćavaju (eksploatišu) od strane oni koji su ih možda otkrili i ćute o tome?
- Koje su moguće posledice?
Značaj sigurnosti softvera
Sa trenutnim repertoarom sigurnosnih napada i pretnji na informacionu sigurnost, softverski arhitekti, programeri, testeri i svi ostali, koji su uključeni u proces razvoja softvera, ne bi trebali dozvoliti prisustvo sigurnosnih ranjivosti koje napadaču mogu poslužiti kao "zadnja vrata". Zato sigurnost ne treba tretirati kao "dodatak" ili "dopunsku radnju" u razvoju softvera, već kao osnovni zahtev samog proizvoda i deo procesa razvoja i celog životnog ciklusa softvera. U tom smislu, prilikom razvoja softvera, značaj uvođenja sigurnosnih mera se ne može dovoljno naglasiti, niti se sme potceniti.
Uvođenje smernica, standarda, procesa i procedura za očuvanje sigurnosti u različitim fazama životnog ciklusa softvera predstavlja neophodnost za očuvanje sigurnosti i privatnosti. Ovakav proaktivni ili, još bolje, prediktivni pristup je neophodan kako za izgradnju poverenja klijenta, tako i za uštede, budući da su ranoj fazi razvoja softvera, sve ispravke mnogo jeftinije. U doba kada korisnici zahtevaju siguran softver, programeri koji uzimaju u obzir aspekt sigurnosti, mogu biti konkurentniji na tržištu.
Kako rešiti probleme sigurnosti softvera?
Adekvatan pristup pregledu, analizi i reviziji programskog koda može značajno pomoći da se unapredi sigurnost softvera. To jeste važan deo procesa od značaja za sigurnost softvera i može se izvršiti na manuelni ili automatski način upotrebom odgovarajućih alata za analizu. Takođe, moguća je kombinacija pomenuta dva pristupa. Međutim, to je samo deo rešenja. Kompletno rešenje ima mnogo više elemenata.Nemoguće je sprečiti sve sigurnosne propuste, ali je potrebno njihov broj držati na prihvatljivom nivou. Informaciona bezbednost je baziranja na riziku i upravljanju rizikom. Držanje prihvatljivog nivoa rizika je jedna od glavnih strategija. Dobra vest je postoje načini: metodologije, procesi i alati koji mogu pomoći u nastojanju da se proizvede što sigurniji softver. Ti načini danas ulaze u fazu sazrevanja. Kao što je Joseph Fineman iz Gartnera rekao: "Sveobuhvatna sigurnost softvera obuhvata kombinaciju ljudi, procesa i tehnologija i gotovo uvek zahteva promenu u načinu funkcionisanja organizacije. Kako sigurnost softvera sazreva, jedino korišćenje takvog modela može pomoći ka preuzimanju inicijative u smislu unapređenja sigurnosti".
Za siguran softver, ili bolje rečeno za ublažavanje sigurnosnih rizika, postoje elementi koji trebaju da budu uključeni u ceo proces razvoja softvera; sigurnost softvera prosto zahteva promene i poboljšanja u celom procesu razvoja softvera. Ona treba da pokrije ceo životni ciklus razvoja softvera. U tom smislu u industriji se koriste termini: Software Security, Application Security, Security Development Lifecycle (SDL), Open Web Application Security Project (OWASP), Software Security Assurance (SSA), Software Assurance Maturity Model (SAMM), Building Security In Maturity Model (BSIMM) i brojni drugi.
Ako ste zainteresovani za više detalja o ovoj temi, možete pročitati sledeći uvodni tekst, koji sam napisao prošlog leta na ovu temu, na društvenoj mreži LinkedIn:
What is wrong with Software Security and how to fix it?
Za više detalja ili pomoć možete me kontaktirati.
Još nekoliko korisnih linkova:
• Open Web Application Security Project (OWASP)
• Software Assurance Maturity Model (SAMM)
• Building Security In Maturity Model (BSIMM)
• CWE - Common Weakness Enumeration
• NVD - National Vulnerability Database
• CVE - Common Vulnerabilities and Exposures
• CVSS - Common Vulnerability Scoring System
• NVD CVSS v2 Calculator
• Secure Coding Initiative